1. Field of the Invention
This disclosure relates generally to verification of integrated circuit designs.
2. Description of Related Art
Designers continue to develop integrated circuits of ever increasing complexity using more and more transistors. Verifying the behavior of a design of electronic circuitry has becoming increasingly difficult and time-consuming. One verification method is software simulation. Software is programmed to perform the same function as the design under test. Verification tests are then run against the software simulator to determine whether the current design functions as desired. A considerable amount of engineering time is spent developing, running and analyzing these software simulation tests and their results. Desiring additional measures of design confidence, chip developers are increasingly turning to other methods of verification.
Another verification method is hardware emulation. Physical hardware, such as FPGAs, is configured to perform the same function as the design under test. Verification tests are then run against the hardware emulator to determine whether the current design functions as desired. An emulator is typically much faster—orders of magnitude faster—than a simulator. In addition, an emulator can also provide other valuable verification capabilities. For example, the emulator can be connected to other hardware that provides a real-world testing environment with real-world input data. The emulator also allows a verification engineer to run pseudo-random tests that cover many more pseudo-random scenarios than a simulator could handle. An emulator can also be connected to a simulator, which can be used to drive the emulator, simulate additional components, or in any combination. Most emulators can be connected simultaneously to a simulator and external physical devices.
However, failures in a verification test suite run on an emulator are more difficult to debug than failures in a verification test suite run on a simulator. A software simulator has known pre-determined input values that make the simulation results reproducible. An engineer typically can stop the software simulation on any cycle, single-step through simulation cycles and perform many other debugging activities.
In contrast, a hardware emulator may not always give reproducible results and typically has much more limited debug support. When the emulator detects a failure, it offers a narrow snapshot of previous activity because of the physical limitations of capturing signal values. A verification test that runs on an emulator for a few hours could spend billions of cycles before an error is detected. The emulator may offer a signal trace for the previous 1 million cycles but the root cause of the failure may have happened much earlier. In addition, an engineer may rerun the test and see different results. On the second run, the failure may not occur or the test may fail in an apparently different manner. Engineers frequently spends weeks debugging emulation failures. Even in situations where the tests performed on the emulator are repeatable, these tests can still span billions of cycles, leading to lengthy debug periods.
Engineers typically debug emulated designs by setting trigger conditions that cause the emulator to capture signal values when the trigger conditions are met. The engineers frequently rewrite the trigger conditions repeatedly until they capture signal values that reveal the root cause. Engineers would benefit greatly if the debugging of emulation failures could be improved.